Existing network architectures in support of Metro Ethernet Forum (“MEF”) services include multiple technologies and multiple vendors. Typically, this will result in complicated logic in breaking down the service request and determining how to map the service attributes to corresponding network device configurations.
For example, a MEF service request with two user network interfaces (“UNIs”) and an Ethernet virtual connection or circuit (“EVC”) is sent from the client to the support system(s) responsible for communicating with the network. The support system must determine the underlying technology (including, but not limited to, virtual private local area network (“LAN”) service (“VPLS”), IEEE 802.1ad (otherwise referred to as “Q-in-Q,” “QinQ,” or “Q in Q”)) and corresponding vendors. The determination of this connectivity can be persistently stored in part or whole. If the technology and/or vendors change, there is typically a significant development effort in order to keep the automation of service request to underlying network activation and corresponding bearer plane flow.
Hence, there is a need for more robust and scalable solutions for implementing communications network methodologies for determination of network connectivity path. In particular, there is a need for a system that overcomes the complexity of multi-technology and multi-vendor networks in support of service activation. Further, there is a need to have a solution that can be used across multiple services, products, and underlying networks for automated service activation.